Docket No.: WELCH 4 



Remarks 

Claims 1, 5-6, 8-11, 15-16, and 18-20 are pending, and claims 1, 5-6, 8-11, 15-16, and 
18-20 stand rejected. The Applicants have not amended the claims in this Response. The 
Applicants respectfully traverse the rejection of the Examiner as follows. 

§ 103 Rejection 

The Examiner rejected claims 1,8-11, and 18-20 under 35 USC § 103(a) as being 
obvious in view of U.S. Patent Application Publication 2005/0065753 (Bigus) and U.S. Patent 
Application Publication 2003/0039352 (El-Fakih). The Applicants submit that the claims of the 
pending application are non-obvious over the cited references. 

To paraphrase claim 1, a telecommunication system is disclosed for distributed system 
monitoring. The system includes peer communication devices that collect performance data 
responsive to handling telecommunications data, and transfer the performance data to a control 
system. The control system processes the performance data from each of the peer 
communication devices to generate a performance file that indicates the performance of each of 
the peer communication devices, and transfers the performance file to the peer communication 
devices. Each of the peer communication devices then processes the performance file to 
compare its performance to the performance of the other peer communication devices to detect a 
fault. Responsive to detection of the fault, one (or more) of the peer communication devices 
processes the performance file to identify a recovery action, and performs the recovery action to 
attempt to cure the fault. 

Thus, as a high level overview, the control system provides a performance file to the peer 
communication devices, and the peer communication devices evaluate their own performance. 
More particularly, a peer communication device processes the performance file to compare its 
performance to the performance of the other peer communication devices to detect a fault, and 
performs a recovery action to attempt to cure the fault. This is truly distributed monitoring 
because the peer communication devices are monitoring their own performance based on the 
performance file provided by the control system. Traditionally, there was a centralized system 
that collected the performance data for peer communication devices, and analyzed the 
performance data of the peer communication devices to find faults. Thus, the centralized system 
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evaluated the performance of the peer communication devices, not the peer communication 
devices themselves. The system monitoring was centralized. Claim 1 is different in that it 
implements distributed monitoring where the peer communication devices evaluate their own 
performance and attempt to cure faults. The Applicants will show that the Examiner has again 
failed to provide any references that teach distributed monitoring as recited in claim 1 . 

Before addressing the rejections of the Examiner, the Applicants will briefly describe the 
cited references. Bigus describes a system that monitors the health of a computer system. The 
computer system includes a server that connects to clients over a network. See FIGS. 1 and 4. 
Each client includes a monitoring agent that compiles metric data about the client (e.g., CPU 
usage), and sends the metric data to the server. See FIG. 4 and \ [0061]. The server includes a 
health monitoring system that stores the metric data over a time period. See FIG. 4 and ]f [0062]. 
The health monitoring system then analyzes the data to discern fuzzy ranges of normal 
performance of the clients and the system as a whole. See FIG. 4 and [0062]. For example, the 
fuzzy ranges may be averages of the metrics in the system, such as an average CPU usage. The 
health monitoring system then stores fuzzy sets representing the fuzzy ranges. See FIG. 4 and ]f 
[0066]. If the health monitoring system wants to evaluate the performance of a client or the 
system as whole, then the health monitoring system collects current metric data, and compares 
the current metric data against the fuzzy sets and fuzzy rules. See FIG. 4 and \ [0066]. For 
example, the health monitoring system is able to determine whether the CPU usage in a client is 
currently above an average usage. The health monitoring system may then provide the results to 
a system administrator through a GUI. See FIG. 4 and \ [0072]. This may be a traffic light icon 
illustrating the present performance. 

Thus, Bigus teaches a centralized server that analyzes the performance of a network, and 
provides the analysis to a system administrator. The Applicants point out that Bigus fails to 
describe providing performance data to peer devices so that the peer devices may evaluate their 
own performance. 

El-Fekih describes a system similar to Bigus, where a centralized server collects 
performance data from elements a network. See \ [0006-0007]. The centralized server then 
analyzes the performance data for the network against performance requirements that were 
guaranteed to customers. This is done to verify that customers are receiving the level of quality 
that they expected. El-Fekih also states that a client (customer) may request a report from the 
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service provider verifying that they are receiving the level of quality that they expected. See | 
[0010]. The report may also be used by the service provider to repair or reconfigure network 
resources. See Tf [0010]. 

Thus, El-Fekih essentially describes a centralized system in a network that receives 
performance data, and analyzes the performance data to determine over overall performance of 
the network. The Applicants point out that El-Fekih fails to describe providing a performance 
file (indicating the performance of each peer device) to peer devices so that the peer devices may 
evaluate their own performance. 

Looking at the limitations of claim 1, the Applicants first submit that the cited art does 
not teach a control system that "processes the performance data from each of the peer 
communication devices to generate a performance file that indicates the performance of each of 
the peer communication devices, and transfers the performance file to each of the peer 
communication devices'" (emphasis added) as recited in claim 1 . Because distributed monitoring 
is implemented in claim 1 , the performance data for each peer device is aggregated together in a 
performance file, and the file is sent to each peer device. This allows the peer devices to 
evaluate their own performance (instead of relying on a centralized system). The Applicants 
submit that neither reference teaches a control system that transfers a performance file as in 
claim 1 to each peer communication device. 

The Examiner has relied on El-Fekih in rejecting this limitation. See page 4 of the Office 
action. El-Fekih broadly states that a report of the network performance may be sent to a 
"customer" so that the customer can verify that they are receiving the proper level of service. 
For example, the report may state "You are receiving 1 .55 Mbps of bandwidth". However, the 
"performance file" in claim 1 indicates the performance of each of the peer communication 
devices. There is no indication in El-Fekih that the "report" provided to the customer indicates 
the performance of each of the peer communication devices. It really would not make sense to 
have a report such as this in El-Fekih, as a customer only wants to know the overall network 
performance. In other words, the customer only wants to know whether they are receiving the 
level of service that the service provider guaranteed. The Examiner has cited to paragraph 
[0010] in El-Fekih, but this paragraph fails to indicate that the report indicates the performance 
of each peer device. Thus, the Applicants submit that the Examiner failed to show how the cited 
art teaches this limitation. 
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Secondly, the Applicants submit that the cited art does not teach "each of the peer 
communication devices, responsive to receipt of the performance file, processes the performance 
file to compare its performance to the performance of the other peer communication devices to 
detect a fault" as recited in claim 1 . In this limitation, a peer communication device receives the 
performance file and processes the performance file to compare its performance to the 
performance of the other peer communication devices. Thus, the peer devices are evaluating 
their own performance based on the performance file. The Applicants submit that neither 
reference teaches peer devices that process a performance file as in claim 1 to evaluate their own 
performance. 

The Examiner has cited to Bigus in rejecting this limitation. See page 4 of the Office 
action. However, Bigus uses a centralized server to collect performance data from the clients, 
and the centralized server evaluates the performance of the clients. The performance evaluation 
in Bigus is then provided to a system administrator through a GUI. However, there is no 
indication in Bigus that the clients themselves process a performance file to evaluate their own 
performance (e.g., identify faults). In rejecting this limitation, the Examiner states that Bigus 
"processes the performance file to compare its performance to the performance of the other peer 
communication devices to detect a fault". See page 4 of the Office action. The Applicants 
completely disagree with this assertion by the Examiner. The Examiner conveniently left out 
what device "processes the performance file". In claim 1, each peer communication device 
processes the performance file to compare its performance to the performance of the other peer 
communication devices to detect a fault. The Applicants have already shown that the clients in 
Bigus do not receive a performance file, and do not process a performance to compare their 
performance to the performance of the other clients to detect a fault. The centralized server in 
Bigus does all of the processing. The Examiner cannot take words out of the limitation merely 
for convenience. This has been an issue in prior Office actions, and the Applicants do not find it 
fair or appropriate. The Examiner needs to consider each word of the limitation, and claim 1 
clearly recites that each peer communication device processes the performance file to compare 
its performance to the performance of the other peer communication devices to detect a fault. 
The Examiner has failed to show how Bigus teaches peer communication devices that operate in 
this manner. Thus, the Examiner's rejection based on Bigus is flawed and cannot support prima 
facie obviousness. 
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Lastly, the Applicants submit that the cited art does not teach "responsive to detection of 
the fault, at least one of the peer communication devices processes the performance file to 
identify at least one recovery action, and performs the at least one recovery action to attempt to 
cure the fault" as recited in claim 1 . In this limitation, not only does a peer communication 
device evaluate its own performance (in relation to other peer communication devices), but it 
also performs the appropriate recovery action to cure a fault. The peer communication device 
does not need to rely on a centralized server (or system administrator) to cure a fault, and it 
initiates its own recover actions. The Applicants submit that neither reference teaches peer 
devices that perform recovery actions as in claim 1 . 

The Examiner has cited to El-Fekih in rejecting this limitation. See page 4 of the Office 
action. More particularly, the Examiner has cited to paragraph [0113] in rejecting this limitation, 
but the Applicants submit that the Examiner has misconstrued this paragraph. El-Fekih states 
that a system may analyze the network performance to determine whether the network is 
performing up to expectations. See ]f [01 13]. If the network performance is deficient, then a 
service provider or customer may be notified (such as by a report discussed above). The portion 
misconstrued by the Examiner is that El-Fekih states that a "client" receiving the report is able to 
take corrective action by reshaping traffic on the network. It would be obvious to one skilled in 
the art that El-Fekih is referring to the service provider as the type of client that is able to take 
corrective action by reshaping traffic on the network. A customer does not have to ability to 
reshape traffic on a network, as a customer is simply a user of the network. The service provider 
has access to management entities that are able to reshape traffic. The Examiner is relying on 
this one statement in El-Fekih to teach a peer communication device that processes a 
performance file to identify a recovery action, and performs the recovery action to attempt to 
cure a fault. This reliance is flawed because El-Fekih does not discuss a peer communication 
device that operates in this manner. A "corrective action" is taken in El-Fekih, but where does 
the reference state that the corrective action is taken in a peer communication device based on a 
performance file? The service provider in El-Fekih may take a corrective action by reshaping 
traffic, but there is no teaching that a peer communication device cures a fault based on a 
performance file as recited in claim 1 . Thus, the Applicants submit that the Examiner failed to 
show how the cited art teaches this limitation. 

In summary, claim 1 describes distributed monitoring where peer communication devices 
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evaluate their own performance based on a performance file, and perform recovery actions when 
a fault is detected. Neither reference cited by the Examiner describes peer devices that operate in 
this manner to evaluate their own performance and perform recovery actions. Both references 
cited by the Examiner use a centralized system that evaluates the overall performance of a 
network and provides reports. However, the references do not teach peer communication 
devices that evaluate their own performance and perform recovery actions. 

Based on these remarks, the Applicants submit that claim 1 is non-obvious in view of 
Bigus and El-Fekih. Similar reasoning applies to the other pending claims. 

Conclusion 

Based on the remarks provided above, the Applicants submit that claims 1, 5-6, 8-11, 15- 
16, and 18-20 are allowable over the cited art. Thus, the Applicants ask the Examiner to 
reconsider the rejections and allow claims 1, 5-6, 8-11, 15-16, and 18-20. 

Respectfully submitted, 

Date: 9-23-2010 /BRETT BORNSEN/ 

SIGNATURE OF PRACTITIONER 

Brett L. Bornsen, Reg. No. 46,566 
Duft Bornsen & Fishman, LLP 
Telephone: (303) 786-7687 
Facsimile: (303) 786-7691 
Customer #: 50525 
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